1. Field of the Invention
The present invention relates to a method for managing protection path bandwidth when using a protection path set up in a loop to recover from a failure occurring in at least a portion of a path, and a method for changing the path bandwidth, and more particularly to a method for managing protection path bandwidth in an MPLS (Multi-Protocol Label Switching) network and a method for changing the bandwidth.
2. Description of the Related Art
To transfer packets such as IP (Internet Protocol) packets at high speed, there has been developed a technology known as MPLS (Multiprotocol Label Switching) in which a short fixed-length label is attached at the head of each packet in addition to the header information contained therein and the packet is transferred using the thus attached label.
Each node maintains a label table which shows incoming interface numbers, outgoing labels corresponding to incoming labels, and outgoing interface numbers. The node that received a packet with a label attached to it determines the outgoing label and the outgoing interface number from the label of the received packet and the incoming interface number by referring to the label table, replaces the label of the packet with the thus determined outgoing label, and outputs the packet on the outgoing interface designated by the thus determined number. This simplifies packet header processing and achieves high-speed packet transfer at layer 2 (refer to RFC3031 and RFC3032).
In the example shown in FIG. 1, node 2 that received a packet 10 having a label A via an IF #1 refers to the label table 12 maintained therein, recognizes that the packet 10 is a packet being forwarded on a path whose path ID is “1”, and determines that the outgoing label is “B” and the outgoing interface number is “2”, therefore, the label is replaced with “B” and the packet is output as a packet 14 from an IF #2. In this way, an MPLS path 16 passing through node 1, node 2, node 3, and node 4 is established.
To establish the path by constructing the label table at each node on the path, the signaling protocol RSVP-TE (Resource reSerVation Protocol-Traffic Engineering) shown in FIG. 2 is used. In FIG. 2, the source node 1 requesting a path setup transmits a PATH message 18, which specifies path identifier (ID 1) and required bandwidth as well as the route (relay nodes) up to the path terminating node 4, hop by hop toward the terminating node 4. Upon reception of the PATH message 18, each of the relay nodes 2 and 3 checks whether the bandwidth requested by the message is available or not, and forwards the PATH message 18 to the next node only when the requested bandwidth is available. Then, the terminating node 4 checks whether the bandwidth requested by the PATH message is available or not and, only when the bandwidth is available, assigns the label (“C” in the example shown) used in the section between the nodes 3 and 4 to this path and returns a RESV message 20 containing this label to the source node 1. Using this RESV message, the label assigned in accordance with the label request is notified to each subsequent node.
JP 2002-344493 and WD3 NCE 03r1, ITU-T, Q3/13, Q9/15, 20-24 September 2004, each describe the use of a ring network to recover from an MPLS path failure. In other words, as shown in FIG. 3, ring networks 22, 24, 26, and 28 are assumed as indicated by dashed lines within an MPLS network which is a mesh network, and failure recovery is performed within each ring network. For example, as shown in FIG. 4, a protection path 30 is set up along the ring connecting the nodes A to F, to recover from failure that may occur on working paths 32 and 34 each of which passes through a portion of this ring. For example, suppose that a link failure occurs between the nodes B and C; then, when a packet arrives at the node B located at one end of the failed link, the label assigned to the protection path 30 is attached at the head of the packet, and the packet is re-routed in the opposite direction along the ring. When the packet arrives at the node C at the other end of the failed link, the label of the protection path is removed, and the packet is transferred in the reverse direction, i.e., in the originally intended direction.
A detailed procedure for setting up a loop MPLS path as a protection path is described in JP 2002-344493.
Here, if prescribed quality is to be maintained when using a protection path, the following relation must be satisfied.Total bandwidth of all working paths≦Bandwidth of protection pathFor this purpose, half of the link bandwidth is fixedly preallocated to the protection path.
However, since every path is not necessarily a path that must be backed up by a protection path to maintain its quality of service, fixedly preallocating the protection path bandwidth would be wasteful of the bandwidth.
Further, when two protection paths, each set up in a loop, share the same link portion, if the bandwidth of each protection path is fixedly preallocated for the shared link portion, there arises the problem that the bandwidth cannot be allocated flexibly, i.e., even when the total bandwidth of the paths protected by one of the loop protection paths is small, the bandwidth of the other loop protection path cannot be increased to increase the bandwidth of the paths that can be protected by that other loop protection path.
There has therefore been a need for a mechanism that can increase or decrease the bandwidth of each protection path as needed, rather than fixedly preallocating bandwidth to each protection path.
RFC3039 describes that the bandwidth of an already established path is changed by exchanging a PATH message and RESV message having the identifier of the same path as the currently set up path and the value of the changed bandwidth between the starting point and the endpoint of the path.
However, no description is given about changing the bandwidth of a loop path or about changing the bandwidth starting from a node other than the node at the starting point of the path. It may be possible to apply the method of this document by taking as the starting point and endpoint the node that was the starting point and endpoint when the loop protection path was set up, but this method cannot be applied directly since the PATH message for the newly set up path does not necessarily pass through this node.